GuardDutyで招待による複数アカウント管理した場合にできることを調べてみた
こんにちは!コンサル部のinomaso(@inomasosan)です。
GuardDutyはAWSアカウント内の全リージョンで有効化することが推奨されていますが、AWSアカウントの数が増えるほど運用負荷が増えていきます。
その辛みを解決するために、GuardDutyには複数アカウントを管理する機能があります。今回はその中でも招待による複数アカウントの管理でどんなことができるのか調べてみました。
まずは絵にしてみた
招待により複数アカウントのGuardDutyを管理した場合の構成図を書いてみました。
こちらの絵を頭の片隅に入れて頂き、以降の文章を読んでみて下さい。
GuardDutyの複数アカウント管理方法
GuardDutyで複数アカウントを管理にするには管理者アカウントを一つ選び以下のいずれかの方法で実施する必要があります。
- Organizationsによるアカウント管理
- AWSアカウントがOrganizationsの組織に参加している必要あり
- 招待によるアカウント管理
- Organizations外のAWSアカウントであれば、管理者アカウントからの招待でメンバーアカウントの関連付け可能
Organizationsによるアカウント管理であれば、メンバーアカウントのGuardDutyを自動有効できることもあり、AWSのドキュメントでも推奨されています。
GuardDuty では、AWS Organizations による方法を使用することをお勧めします。組織の設定については、[AWS Organizations ユーザーガイド] の「組織の作成」を参照してください。
- 引用: Amazon GuardDuty で複数のアカウントを管理する | AWSドキュメント
一方で、数アカウント程度であればOrganizationsで運用するためのOU/SCPの設定や運用等で負荷が増えてしまうケースがあります。
以下のような課題感を解決するためにOrganizationsの導入を検討している等でなければ、招待によるアカウント管理を選択していただくのが良いかと思います。
- AWSアカウントが増えて、部門ごとのセキュリティ対策にバラツキがある
- AWSアカウント/IAMの管理を、個別に実施するのが運用上の負担になっている
招待によるアカウント管理で実行できること
GuardDutyの主な機能に対して、招待によるアカウント管理した場合に管理者アカウントとメンバーアカウントで実行できることを、それぞれまとめてみました。
脅威検知の結果表示
AWS環境で潜在的なセキュリティリスクに関するアクティビティを検出すると、GuardDutyにより検出された結果(Findings)が生成されます。
アカウント | アクション |
---|---|
管理者 | 全アカウントの結果を表示可能 |
メンバー | 自アカウントの結果のみ表示可能 |
使用状況の表示
GuardDutyの1日あたりの推定コストや、データソース(ログ)毎の詳細な内訳を表示できます。
アカウント | アクション |
---|---|
管理者 | 全アカウントの推定コストや内訳を表示可能 |
メンバー | 自アカウントの推定コストや内訳のみ表示可能 |
抑制ルールを適用
指定した条件に一致する新しい結果を自動的にアーカイブすることができます。
アカウント | アクション |
---|---|
管理者 | 管理者アカウントで適用可能 |
メンバー | 自アカウントで適用不可 |
結果をアーカイブ
GuardDutyの結果の調査が完了したら、その結果をアーカイブすることができます。
アカウント | アクション |
---|---|
管理者 | 全ての結果に対して操作可能 |
メンバー | 自アカウントで操作不可 |
リスト管理
以下のリストをユーザ側で作成することにより、GuardDutyのモニタリング範囲をカスタマイズすることができます。
- 信頼されているIPリスト
- 信頼済みIPリスト上のIPアドレスに対して、GuardDutyはVPCフローログやCloudTrail管理イベントの結果(Findings)を生成しなくなります。ただし、DNSログは対象外のため、結果(Findings)は生成され続けます。
- 結果(Findings)のノイズを低減するために、GuardDutyでは信頼済みIPリストの代わりに抑制ルールの使用が推奨されています。抑制されても結果(Findings)は生成され、すぐにアーカイブされるため、アーカイブされた後も確認することができるからです。
- 脅威リスト
- GuardDutyのモニタリング範囲外の可能性がある、業界固有の脅威フィードやサードパーティプロバイダの悪意のあるIPアドレスに対して結果(Findings)を生成することができます。
アカウント | アクション |
---|---|
管理者 | 全アカウントに一括で適用可能 |
メンバー | 自アカウントで適用不可 |
S3保護
GuardDutyはデフォルトで、ListBuckets、DeleteBuckets、PutBucketReplicationなどのバケットレベルのAPI操作を含む、S3リソースに関わるCloudTrail管理イベントを分析します。
S3保護を有効にすると、オブジェクトレベルのAPI操作であるListObjects、DeleteObject、PutObjectなどのCloudTrailデータイベントが分析されます。
これにより、S3バケット内のデータに対する潜在的なセキュリティリスクを特定することができます。
アカウント | アクション |
---|---|
管理者 | 全アカウントへ個別に設定可能 |
メンバー | 自アカウントで設定不可 |
Kubernetes Protection
Kubernetes Protectionを有効化すると、EKS内のKubernetesクラスターの不審なアクティビティや潜在的な侵害を検出することができます。
アカウント | アクション |
---|---|
管理者 | 全アカウントへ個別に設定可能 |
メンバー | 自アカウントで設定不可 |
GuardDuty停止または再有効化
GuardDutyを一時停止または再有効化で、GuardDutyの一時的なサービス停止が可能です。
アカウント | アクション |
---|---|
管理者 | 管理者アカウントで操作可能 |
メンバー | 自アカウントで操作不可 |
管理者アカウントへのログ集約
GuardDuty脅威検知後の調査・対応のために、CloudTrailやVPC Flow Logsのログを管理者アカウントに集約したい場合、GuardDuty自体に該当機能は存在しないため個別に実装する必要があります。
分析するためのCloudTrailやVPC Flow Logsのログについては、利用者が有効化していなくてもAWSがバックグラウンドで取得している情報を使うため、GuardDutyを利用するためにそれぞれを有効化する必要はありません。ただし、実際に脅威を検知したあと調査をする段階で役に立つため、それぞれのログも有効化しておくと良いでしょう。
- 引用:【初心者向け】AWSの脅威検知サービスAmazon GuardDutyのよく分かる解説と情報まとめ)
ログ集約の実装方法につきましては、以下をご参照願います。
複数アカウント管理時のGuardDuty分析料金
GuardDuty コストの見積もりや、実際の利用料金を確認する限り、各アカウントでGuardDutyの分析費用が発生するようです。
参考URL
まとめ
GuardDutyの招待で複数アカウントを管理した場合に、どういったことができるのかについてブログにまとめてみました。
この記事が、どなたかのお役に立てば幸いです。それでは!